home *** CD-ROM | disk | FTP | other *** search
- Editor's Note: Minutes received 8/12
-
- CURRENT_MEETING_REPORT_
-
-
- Reported by Allan Cargille/UWisc
-
- Minutes of the X.400 Operations Working Group (X400OPS)
-
- First Session
-
- Alf Hansen Chaired the meeting. Allan Cargille volunteered to take
- Minutes. The Agenda was modified to discuss Working Group status and
- the status of the Wisconsin NSF X.400 Project and the Cosine MHS
- Project.
-
- Alf distributed the new Charter before the meeting. It was agreed that
- the proposed new time schedule for the documents would be revised after
- discussion of the documents. Note: this was not done in the meeting,
- and should be done on the mailing list. Action - Alf
-
- Other issues discussed during the first session included:
-
-
- o Change control. The IESG (and IAB ?) agreed that change control
- for RFC1327 (the latest version of mapping between X.400 and RFC822
- mail) was assigned to the RARE Working Group on Mail and Messaging.
- This prompted the following discussions:
-
- - Is it OK for IETF RFCs to be assigned to another group?
-
- - How will people in the x400ops Working Group be able to
- participate in further revisions of this document?
-
- - How will this be publicized ?
-
- It was clarified that the RARE-MSG Working Group is an open Working
- Group. Members of the x400ops Working Group are welcome to join
- the mailing list and participate in the Group. Here's how to join:
-
- Send a message to MAILSERVER@RARE.NL with the following text in
- the BODY of the message (NOT the subject).
-
- SUBSCRIBE WG-MSG Your-given-name Your-surname
-
- This will automatically subscribe you to the list. An automatic
- reply will be sent back to you.
-
- The address of the mailing list itself is wg-msg@rare.nl, or
- /S=wg-msg/O=rare/PRMD=surf/ADMD=400net/C=nl/.
-
- o There was also discussion about the number of mailing lists which
- deal with X.400 issues. Often messages are posted to multiple
- lists. It was recognized that having these multiple lists is a
-
- 1
-
-
-
-
-
- pain, but this Working Group is unlikely to be able to change the
- situation. It was recommended that when an initial message is
- posted to multiple lists, the message should clearly identify *one*
- list on which the follow-up discussion should take place.
-
- o Action items from last March 92 meeting:
- a. John Sherburne (SPRINT) will work with Tony Genovese to figure
- out how US can provide an MTA that has X.25 connectivity.
-
- - Tony reported that accepting ADMD = <single space> is a problem
- for Sprint. He did not know if that is for technical,
- political, or financial reasons.
- [action] Tony continue to work on a WEP which is accessible
- over public X.25.
-
- - Ed Albrigo from the Corporation for Open System (COS) gave a
- report on their X.400 activities. They are working on the
- following:
-
- 1. Establishing direct network-layer connections to the
- Internet. They plan to route both IP and CLNP.
-
- 2. Establishing X.400 links which connect the OSINet X.400
- community to the GO-MHS community.
-
- 3. They are planning to go to complete ``electronic-only''
- communication with ten COS member companies by December
- 1992.
- Ed confirmed that COS will comply with current RFCs and
- recommendations for the GO-MHS community.
- It was clarified that COS uses X.25 in their private OSINet
- network, but that is a private network that is not connected to
- public X.25.
-
- - There was a discussion about connections to ATTmail. Internet
- RFC822 mail users should be able to send mail to all ATTmail
- users. However, the ATTmail <--> Internet mail gateway
- produces bad addresses, so mail is often un-replyable.
-
- b. Urs will ask the COSINE MHS Project Team to submit the address
- mapping table procedures as a draft RFC. - Done.
- c. Stef - Start a discussion on X.400 OPS and WG1 lists about ADMD
- name in the U.S. See section 3.1.2. [of March 1992 Minutes]
-
- - Not done.
-
- - Note that the rare-wg1 mailing list has been succeeded by the
- wg-msg list (see section 2 above).
-
- 2
-
-
-
-
-
- [action] Stef start this discussion. [action] Someone email
- Stef to start this discussion. [done]
- See related discussion of this in Agenda item 5.
-
- d. Alf will send the updated Charter to the list. - Done
- e. Claudio will produce a draft document that will propose a
- method for using DNS to store X.400 to RFC 822 mapping and routing.
- - Done.
- f. Claudio will follow up the MAIL 11 mapping document. - Done
- g. Harald will follow up the International Character set document.
- - Done
-
- o Status of X.400 Operations
- a. Allan Cargille discussed the status and future of the NSF X.400
- Project. The project has been running since August, 1990 and is
- now toward the end of the initial grant. The project has operated
- the experimental PRMD ``XNREN''. Fifteen to twenty sites have
- registered as members of this PRMD, but only approximately five are
- currently exchanging X.400 traffic. The project has acted as a
- coordination point for U.S. entries in the RFC987/1148/1327 mapping
- tables. The project also served as a beta site for several PP
- releases, and developed and contributed software to support the
- Fujitsu dexNET 200 fax modem in PP. The project is operating a
- primary MTA running PP 6.0 on a dedicated DecStation 3100/Ultrix.
- Some sites, including Wisconsin, are running the IBM/Wisconsin Argo
- X.400 software, which includes a UA. The project has also acted as
- a Well-Known Entry Point (WEP) to the Cosine MHS Project (see
- below). We are seeking an extension of the grant to continue
- supporting a stable U.S. WEP and to participate in the ongoing
- research work to develop a stable X.400 infrastructure. Without
- continued funding, our project will end at the end of this calendar
- year.
- b. Jim Romaguera presented an overview of the Cosine MHS Project
- at SWITCH (Switzerland). That project began in (January 1991 ?)
- and continued work begun by the RARE MHS Project Team. They
- coordinate the academic and research X.400 service in Europe. They
- have finished 80 percent of their goals for the current project
- period, which ends at the end of this calendar year. The project
- supports international X.400 connections between all Western
- European countries, as well as Greece, Slovenia, Lithuania, the
- United States, Canada, Australia, New Zealand, South Africa, China,
- India, and the Republic of Korea. Some countries have multiple
- networks participating in the service. Most European participants
- have private connections to one or more commercial ADMDs. Some are
- purchasing value-added services (such as fax gateways) from ADMDs.
- Several project participants have online services available (via
- telnet or over X.25) to translate between X.400 and RFC822
- addresses according to the current mapping rules.
- The exact future of the project is unclear, but it is expected that
-
- 3
-
-
-
-
-
- they will continue. It is likely that the future project will be
- coordinated by the RARE Operational Unit and will be contracted
- out.
- The project team is still working on several projects. They plan
- to have a daily RFC1327 mapping table update tool operational by
- the end of this year. They are working on evaluating publicly
- available X.400 implementations. They plan to produce a catalog of
- existing X.400 implementations. They have done work on evaluating
- ADMDs and plan to report on this (verifying connectivity, etc).
- They plan to produce a tutorial and overview on RFC1327. They have
- done work on evaluating international X.400 connections, and are
- working on tools to automatically process a common statistics
- format. They are also working on a connectivity tool which will be
- based on sending mail to echo servers and evaluating the results.
- Lastly, they operate a file server with lots of documents. You can
- reach the fileserver via anonymous ftp to host ``nic.switch.ch''.
- Discussion:
-
- - It was recommended to refer to RFC1292 (a catalog of X.500
- implementations) for X.400 product evaluations.
-
- - Will this information on implementations be released as an RFC
- ?
-
- - There is a question of liability when producing such
- evaluations.
-
- - It was recommended that vender and user comments about
- implementations be placed in separate documents.
-
- c. Stef reported on the current work of the MHS-MD study group on
- ADMD/PRMD naming. By way of review, Stef covered the history of
- connections between the U.S. Internet and commercial email
- services. Vint Cerf was the founder of MCI Mail and then went to
- CNRI. He concluded agreements on behalf of the Internet with
- MCIMail, ATTmail, G.E. Information Services, and CompuServe (and
- possible others) that are ``sender keeps all revenue'' agreements.
- There was also discussion about what internal protocols these
- services use. All operate gateways between RFC822 and their
- internal protocol. Several problems were discussed.
-
- - If the service is using a poor or nonstandard gateway, then the
- addresses coming out of the gateway are messed up.
-
- - People did not know of any connections between U.S. commercial
- ADMDs.
-
- - There are no connections between the U.S. Internet X.400
- community and commercial ADMDs.
-
- 4
-
-
-
-
-
- Current MHS-MD status. Commercial ADMDs have been arbitrarily
- selecting their own names, and then arbitrarily naming PRMDs under
- their ADMD. There is strong feeling that these existing (ADMD,
- PRMD) name pairs must be valid in the future. Any new registration
- procedure must support these existing names. The Group is also
- working on a structure for a U.S. ADMD backbone, which does not
- mean a specific ADMD. Currently the string ADMD=USBB is being used
- to refer to such a structure. Stef cautioned us that the ``USBB''
- name is just a placeholder and is likely to change to some other
- (as yet undefined) text string. PRMD names could then be
- registered under this ``ADMD=USBB''. There are still unresolved
- questions about how the USBB should be routed and supported.
- Stef proposed that the U.S. Internet declare itself as an ADMD.
- This could be justified because at present, all the other ADMDs are
- self-declared as well. Stef argued that there is currently no
- regulation of US X.400 service providers, so each ADMD is more or
- less making up their own rules as they proceed. Many people are
- making lots of assumptions. One has been that the INTERNET does
- not qualify to be an ADMD, and the that other ADMDs would block its
- attempt to assert that it is an ADMD.
- Discussion:
-
- - The issue of connecting to the U.S. ADMDs is not an issue of
- naming, it is an issue of service agreements and charging. The
- routing can be worked out.
-
- - Connections over X.25 will probably be necessary to connect to
- the commercial ADMDs, although many US carriers are moving to
- offer IP service, and to interconnect with the INTERNET.
-
- - The Internet ADMD could offer to provide RFC1327 gateway
- services to the commercial ADMDs. That way the gateways would
- be operated according to existing agreements and
- recommendations and would generate ``good'' addresses.
-
- - If the Internet succeeds in defining itself as an ADMD, then
- the other C=US ADMD service providers can no longer use the
- excuse that they ``cannot pass ADMD-ADMD traffic via the
- INTERNET PRMD''.
-
- - If the commercial services were interested, the Internet ADMD
- could play a role as a relay between them. [Note - this would
- not necessarily require commercial traffic to flow across the
- research Internet.]
-
- There was a proposal to decide on the matter at this meeting.
- There was heated argument that the issue had not been discussed
- before the meeting, and should be discussed more in a wider forum
- and on the mailing list. It was agreed that Stef would write an
- internet draft proposing to create an ADMD=Internet [action]. If
-
- 5
-
-
-
-
-
- approved in the future, this paper could evolve into an RFC.
- The Working Group recommended that each country should write an
- Internet Draft describing the national solution for X.400
- addressing of Internet addresses. Stef's draft could be used as a
- template for other countries' Internet Drafts. The result will in
- the end be (if the drafts are approved) a series of RFCs. [This
- paragraph supplied by Alf Hansen.]
-
- o Future U.S. Internet X.400 organization - not discussed beyond the
- above information.
-
-
- Second Session
-
-
- o Continuation of Connections to ADMDs Discussion. - Steve H-K.
- proposed generating a document that addresses the issue of ADMDs
- and how they are connected to the R&D world (or ``Internet'' to
- coin a phrase). The contents of this document should be something
- like:
-
- - ADMDs presently connected to the Internet (or R&D world, same
- thing, as I'm talking about the global Internet).
-
- - Policy restrictions on such connections ie. are they available
- for free & for anyone on the Internet, can R&D people relay via
- a connected ADMD to 3rd party ADMDs , etc.
-
- - Whether the ADMDs are using RFC 1327 gateways & the global
- mapping tables
-
- - Which PRMDs these ADMDs support - ADMD connectivity between
- themselves. - anything else that fits in to the above context.
-
- Goals are to:
-
- - Stimulate ADMDs to deploy well run ADMD to Internet
- connections, preferably by using R&D operated gateways.
-
- - Document the PRMDs reachable via ADMDs and of course the ADMD's
- connectivity to other ADMDs.
-
- Jim Romaguera (wearing the hat of NetConsult AG, not the Cosine MHS
- Project Team) volunteered to write a draft document [action].
- [notes in this (cont'd) section courtesy of Jim R.]
-
- o Document Review - in general, detailed comments are not included if
- a new version of the document will be released.
- a. ``X.400 use of extended character sets'' (Harald Alvestrand).
-
- 6
-
-
-
-
-
- Discussion. Harald will update the document and release the
- updated version as an Internet draft [action]. The draft will be
- discussed at the upcoming RARE Character Set and RARE Messaging
- meetings. These comments will be presented at the next IETF
- meeting, and the document will be finalized.
- b. ``Operational Requirements for X.400 Management Domains in the
- GO-MHS Community'' (Hansen/Hagens). Comments were taken on the
- document. The document will be revised and a new Internet Draft
- will be released [action].
- There was discussion about what kind of RFC this document should be
- released as. People felt that it should be a requirement that
- X.400 domains should support the ``postmaster'' address in the same
- manner as RFC822 domains do. It was proposed that a very short RFC
- be drafted which explains the need for supporting ``postmaster''
- addresses. This short postmaster RFC will then be advanced in the
- standards track. Allan Cargille volunteered to write the RFC
- [action]. It will use the recommendations from the recent Cosine
- MHS Managers meeting as a starting point. It was pointed out that
- to support the introduction of X.400(88), both S=Postmaster and
- CN=Postmaster must be supported.
- The revised Hansen/Hagens paper cannot be progressed as an RFC
- until the Eppenberger routing paper and Cargille Postmaster paper
- are also ready to be submitted, because it references those
- documents. The document may also have to be modified based on the
- group's recommendations for C=us/ADMD=Internet.
- c. ``Routing coordination for X.400 MHS services within a
- multi-protocol/ multi-network environment'' (Urs Eppenberger).
- Changes to this document were discussed in light of a recent
- submission by Panos Tsigaridas, ``MHS Information Exchange Format''
- (MHS-IEF). Panos' paper recommended using the same basic
- information and routing algorithm as the Eppenberger document, but
- providing a syntax and structure so that this information could be
- easily placed into X.500 under well-known places. Further
- information already stored in X.500 could easily be extracted by
- tools and translated into the proposed text format. These text
- tables could then by exchanged the ``old-fashioned'' way (E-mail).
- The desire to support X.500 must be weighed against the fact that
- this new document format is needed immediately and in fact is
- already being introduced in the Cosine MHS Project. Changing the
- document format would introduce delays due to discussion and take
- longer to become operational. It was agreed that Urs, Panos, and
- Steve H-K. would meet to see if minimal changes could be made to
- the Eppenberger document which would make it easier to store the
- information in X.500. Steve reported that they agreed that Panos
- would propose a set of detailed ``short term'' change requests to
- Urs's document [action]. A revised document should be sent out,
- which should be approved via email and then submitted as an
- experimental RFC [action].
- d. ``Using the Internet DNS to maintain RFC987/RFC1148 Address
- Mapping Tables and X.400 Routing Informations'' (Allocchio, Bonito,
-
- 7
-
-
-
-
-
- & Giordano). All three tables will be stored under the domain
- ``.x400.arpa''. Change control will still be centralized -- the
- tables will still be collected and managed by the Cosine MHS
- Project Team. The use of the DNS tables will be described in a
- separate document [action]. Mapping conventions are used to
- represent the RFC1327 table entries in a format that is legal for
- the DNS. Claudio will produce a new version of the document, and
- distribute it to the DNS and x400ops mailing lists [action]. If
- consensus is reached, the document will be submitted as an
- Experimental RFC.
- e. OSI area procedures. Erik Huizer requested that to progress a
- document in the OSI area as an Internet Draft, people should send
- email to Dave Piscitello (dave@sabre.bellcore.com), himself
- (huizer@surfnet.nl) and CC the IESG Secretary Greg Vaudreuil
- (gvaudre@nri.reston.va.us). [Note - this information should
- probably be sent to all the OSI area working groups. [action]]
- Erik also reported the following procedures for IETF OSI working
- groups [actions]:
-
- - He will create a mailing list for these Working Group Chairs.
- - He will distribute each message to him from higher IETF people
- to Working Group Chairs (Chairpersons).
-
- There was also discussion about what classes of RFCs there are.
- RFCs *not* on the standards track can be classified as
- ``Informational'' or ``Experimental''. RFCs on the standards track
- proceed from ``Proposed Standard'' to ``Draft Standard'' to
- ``Standard''. [Note - is this documented in an RFC?] It was also
- pointed out that RFCs cannot reference Internet Drafts, but they
- may reference any class of RFC.
-
- o Major Operation Problem - not discussed.
-
- o Review of Action Items - deferred to mailing list, due to time.
- See below.
-
- o Any Other Business, and plan for next meeting - Erik Huizer (OSI
- Area Co-Director) proposed to resume the ``old'' meeting schedule
- for the OSI area at the next IETF. Other than that, the next
- meeting schedule not discussed. Erik will distribute this new
- schedule [action].
- We decided to have the next x400ops meeting at the next IETF
- meeting in Washington DC, U.S.A., during the week Nov. 16-20,
- 1992.
-
-
- Revised Summary of Action Items
-
-
- Allan Cargille Distribute draft Minutes. - Done.
-
- 8
-
-
-
-
-
- Alf Hansen Revise timetable for documents on new Charter by
- discussion on the list.
- Update Operational Requirements document and
- release as an Internet Draft.
- Tony Genovese Continue to work on a WEP which is accessible
- over public X.25.
- Einar Stefferud Start discussion on mailing lists about U.S. ADMD
- naming issues. - Done.
- Write an Internet Draft proposing to create
- ADMD=Internet.
- Someone Email Stef to start this discussion. - Done.
- Jim Romaguera (NetConsult AG) Generate draft document that
- addresses the issue of ADMDs and how they are
- connected to the R&D world.
- Harald Alvestrand Update document on extended character sets and
- release as an Internet Draft.
- Panos Tsigaridas Provide a set of detailed ``short term'' change
- requests to Urs' routing document.
- Urs Eppenberger Release revised version of routing coordination
- document (if there are any changes). Hopefully
- get consensus on mailing list about the document
- and submit as an RFC.
- Claudio Allocchio Produce new version of the X.400 DNS paper and
- distribute it to the x400ops and DNS mailing
- lists. If consensus is reached, submit document
- as Experimental RFC.
- Produce new document explaining how the X.400 DNS
- tables should be used and distribute to x400ops
- list.
- Erik Huizer Distribute information on the procedure for
- progressing a document in the IETF OSI area to
- all area mailing lists.
- Create a mailing list for IETF OSI area Working
- Group Chairs.
- Distribute working group meeting schedule for OSI
- area for next IETF meeting.
-
-
-
- Attendees
-
- 9
-
-
-
-
-
- Ed Albrigo ealbrigo@cos.com
- Claudio Allocchio c.allocchio@elettra.trieste.it
- Harald Alvestrand Harald.Alvestrand@delab.sintef.no
- C. Allan Cargille cargille@cs.wisc.edu
- Chris Chiotasso chris@artel.com
- Cyrus Chow cchow@orion.arc.nasa.gov
- Alan Clegg abc@concert.net
- Curtis Cox ccox@wnyose.nctsw.navy.mil
- Richard desJardins desjardi@boa.gsfc.nasa.gov
- Tom Easterday tom@cic.net
- Urs Eppenberger eppenberger@switch.ch
- Tom Farinelli tcf@tyco.ncsc.mil
- Osten Franberg euaokf@eua.ericsson.se
- Jisoo Geiter geiter@gateway.mitre.org
- Tony Genovese genovese@nersc.gov
- Arlene Getchell getchell@nersc.gov
- Alf Hansen Alf.Hansen@delab.sintef.no
- Steve Hardcastle-Kille s.kille@isode.com
- Erik Huizer huizer@surfnet.nl
- Takashi Ikemoto tikemoto@xerox.com
- Kevin Jordan kej@udev.cdc.com
- Mark Knopper mak@merit.edu
- Jim Romaguera romaguera@cosine-mhs.switch.ch
- Einar Stefferud stef@nma.com
- Panos-Gavriil Tsigaridas tsigaridas@fokus.berlin.gmd.dbp.de
- Linda Winkler lwinkler@anl.gov
- Steven Winnett swinnett@bbn.com
- Russ Wright wright@lbl.gov
-
-
-
- 10
-